Contact centers, such as Automatic Call Distribution or ACD systems, are employed by many enterprises to service customer contacts. A typical contact center includes a switch and/or server to receive and route incoming packet-switched and/or circuit-switched contacts and one or more resources, such as human agents and automated resources (e.g., Interactive Voice Response (IVR) units), to service the incoming contacts. Contact centers distribute contacts, whether inbound or outbound, for servicing to any suitable resource according to predefined criteria. Normally in present-day ACDs when the ACD system's controller detects that an agent has become available to handle a contact, the controller identifies all predefined contact-handling skills of the agent (usually in some order of priority) and delivers to the agent the highest-priority oldest contact that matches the agent's highest-priority skill.
The primary objective of contact center management, including call-distribution algorithms, is to ultimately maximize contact center performance and profitability. An ongoing challenge in contact center administration is monitoring of agent behaviors to optimize the use of contact center resources and maximize agent performance and profitably. Current products for monitoring and reporting on contact center performance, such as Call Management System or CMS™ by Avaya Inc., and Operational Analyst or OA™ by Avaya Inc. are configured as data warehouses that extract data from multiple sources, transform the data into a standardized form, and load the data into the data warehouse database. Additional calculations and reporting may be performed after the batch load. As will be appreciated, accurately tracking date and time are crucial to contact center monitoring. The fundamental measurements are about how agents are spending their time and how effective the contact center is over time.
Providing fundamental performance measures in contact centers is no simple task. The time scale of contact center data is enormous. In addition to simply labeling events according to the time they happened (e.g., 2005-10-01 01:00:00), a contact center clock must also tag events with the variously sized intervals that contain them so that time can be partitioned evenly (e.g., to know that the clock time in the prior example is both the start of the second hour and the third hour of that day, since it is a day of fall daylight saving transition in some time zones). Fine scale data must be recorded with precision of at least one second (preferably one millisecond) and arrives at a rate on the order of a thousand rows per second; that is the scale is on the order of 0.001 seconds. Large scale data is typically kept for three or more years; that is, it is kept for 100,000,000, seconds. That is a factor of 100,000,000,000 between large and small scale data.
The global scope of even a single contact center reporting center requires additional flexibility in handling date and time. The same data must be equally presentable in a local time zone, where a local supervisor is managing agents, and in an enterprise or client specific time zone where enterprise management is managing the entire contact center. For example, at the enterprise (e.g., regional or global) level the same performance data is joined in a different common time zone to analyze the balancing of traffic load between local centers and to demonstrate to clients that their contractual service objectives are being met. The set of time zones required for a particular reporting system typically depends on the locations of the various centers being supported, so it varies with system configuration.
Global time zones are more varied than is commonly realized. There are sixteen time zones in the world that are on half hour boundaries with respect to Greenich and one of them (India) is an important market for contact centers. There are even two time zones that are on quarter hour boundaries (Nepal is one). Fractional hour time zones increase the naïve count of global time zones from twenty-four to forty-two. But by far the greatest complexity in global time zones is due to daylight saving time. Time zones are differentiated not only by whether they do daylight saving time but by when they do daylight saving. The transition points in fall and spring differ by day of year (e.g., Europe enters on last Sunday in March while United States currently enters on the first Sunday in April) and by time of day (e.g., 3 a.m., 2 a.m., 1 a.m., and 11:45 p.m.). Daylight saving effects raise the count of global time zones to over five hundred (Java v. 5 recognizes 561).
Not only do daylight saving rules differ, they also change. In the United States, the period of daylight saving time will be extended by 3 weeks in spring and 1 week in fall, beginning in 2007 In 2006, Indiana is also ending its peculiar local tradition of three time zones. Daylight saving rules are so complicated, if you perform a Google™ search for the rules you will likely find predictions for the current year rather than algorithms. Even worse, the knowledge of time zones in Java does not attempt to represent historical variations in the rules but only the current rules.
Existing contact center reporting systems store all data in a single, universal time zone (UTC, a.k.a. GMT) and pass off all time zone conversion responsibilities to special reporting proprietary software. The reporting code could remap ranges of 30-minute grain summary data into the time zone of the report user, but daily, weekly, and monthly grain summaries are constrained to a preferred time zone, known in OA as the Archive Time Zone (ATZ). The selection of this time zone had to be made before the data could be summarized so the choice was frozen into the data, rather than being a choice by the user. Because of the peculiarities of international time zones and daylight saving time rules, the approach of handling all time zone conversions in the reports made reporting software too complicated for third party OnLine Analytical Processing (OLAP) tools. The result was that such tools had to display results only in the universal time zone of the data, which in many cases caused graphs of the work day to be broken into two pieces around UTC midnight.
Increasingly contact center reporting systems are using data warehouse techniques to organize data. In dimensional modeling or data warehousing, numeric performance measures (the things that are typically added up) are kept in special “fact tables” separate from the descriptive attributes (such as names and identifiers) which are kept in “dimension tables.” Foreign keys in the fact tables link the measures to the individual dimension rows they describe. Typically, there are multiple foreign keys in a fact table, since the measures may be about the combination of entities from different dimensions (e.g., about a particular agent from the agent dimension answering calls in a particular queue in the queue dimension).
It has been suggested that data warehouses handle data and time as a single dimension but this approach is dismissed in the prior art as leading to an enormously sized resulting dimension table. There are over 31 million seconds in a year so keeping 10 years of data at one second resolution would require over 310 million rows in that dimension table. Instead, the standard technique is to split data and time into separate dimensions of dramatically smaller size (3,650 rows in the date dimension for 10 years and 1,440 or 86,400 rows in the time dimension for resolutions of either one minute or one second, respectively). In recent years, this standard technique has grown to include a full date-time time stamp as a separate measure in the fact table in addition to the foreign keys pointing to the date and time dimensions. Other variants dispense with the time dimension altogether. In all cases, multiple time zones require multiple sets of foreign keys/time stamps in the fact tables.
Time zone handling is the Achilles heel of conventional dimensional data models. They fail in partitioning time on the days of daylight saving transition, even in a single time zone (e.g., data from the second and third hours of the day during the transition out of daylight savings time get lumped together and there is no recognition of twenty-three hour and twenty-five hour days). The cost of time zones in database space (and consequently in access speed) discourages support of enough time zones for reporting needs (a typical warehouse with only four time zones is already using most of its space just on time stamps). And because of the way time stamps are frozen into the largest database tables, it is not feasible to alter the choice of supported time zones during the lifetime of the data warehouse (without shutting down the contact center for week-long data migration). Attempts to use multiple time stamps in the date and time dimensions to describe multiple time zones (as synonymous labels for the same instant of time, as seen from different time zones) fail because there are hours of the day for which different time zones disagree on the date and the time of day. Another way to understand this failure is to see that the choice of a particular date in a date dimension is equivalent to favoring only those time zones that agree with that choice of day. Putting the multiple time zone information in the fact tables significantly increases database size and with a consequent decrease in database performance (it is slower). The sheer size of fact tables also means that you cannot change which time zones should be supported, since it would require a complete rewrite of all fact table rows and even a schema change (to include more time zones). Such massive changes in fact tables are known from data migration experience to require up to a week or more of down time.